What is the problem this PR solves?

This PR handles new available_rollbacks field sent by elastic-agent during checkin (implemented in PR elastic/elastic-agent#11143).
This information will be consumed by the Fleet UI to allow a manual rollback of recently upgraded agents.

How does this PR solve the problem?

This PR introduces new available_rollbacks field both in CheckinRequest and pendingT structs as a slice of AvailableRollbacks and a JSON array of objects respectively.
On Elasticsearch the documents in .fleet-agents will have a new field upgrade.rollbacks similar to:

...
"upgrade": {
            "rollbacks": []
  },
..

How to test this PR locally

Refer to PR elastic/elastic-agent#11143 How to test this PR locally section.

Design Checklist

• I have ensured my design is stateless and will work when multiple fleet-server instances are behind a load balancer.
• I have or intend to scale test my changes, ensuring it will work reliably with 100K+ agents connected.
• I have included fail safe mechanisms to limit the load on fleet-server: rate limiting, circuit breakers, caching, load shedding, etc.

Checklist

• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in ./changelog/fragments using the changelog tool

Related issues

• Relates Support manual rollback for Fleet-managed agents elastic-agent#11143